…play correto sob concorrência na idempotência

Adiciona @Version (coluna version, migration V5) em charges. ProcessWebhookService
e ChargeExpirationJob podiam sobrescrever a mesma charge concorrentemente sem
avisar ninguém. No webhook, o conflito agora propaga OptimisticLockingFailureException
até o GlobalExceptionHandler, que responde 409 (o provedor reenvia; dedup por
event_id garante que reprocessar é seguro). No job de expiração, extrai
ChargeExpirationCoordinator (@transactional por charge, evitando o self-invocation
que anularia a anotação) para que uma charge em conflito seja pulada nesse ciclo
sem impedir as demais de serem processadas.

ProcessWebhookService agora valida o status recebido antes de qualquer transição,
lançando InvalidChargeStatusException (422) em vez de deixar um IllegalArgumentException
cru virar 500.

CreateChargeService: duas requisições concorrentes com a mesma Idempotency-Key nova
faziam a perdedora receber um 500 da violação de unicidade, mesmo com o rollback já
evitando duplicar dados. Extrai ChargeCreationCoordinator (@transactional) para a
escrita; ao capturar DataIntegrityViolationException UMA CAMADA ACIMA da transação
(depois do rollback completo do Postgres), CreateChargeService busca o registro de
idempotência da vencedora numa transação nova e retorna o replay em vez do erro.

Testes cobrem os três cenários; a concorrência real (duas threads com a mesma key)
é provada via Testcontainers em CreateChargeServiceConcurrencyIT.

… testes

ChargeJpaEntity agora implementa Persistable<UUID> com isNew() baseado em
(version == null). O id da Charge é atribuído em código (UUID.randomUUID()),
não pelo banco, então Spring Data não tinha como distinguir insert de update
só pelo id e sempre chamava merge() — com @Version presente, merge() de uma
entidade nova faz o Hibernate suspeitar que a linha foi apagada por outra
transação e lança ObjectOptimisticLockingFailureException.

Corrige também OutboxClaimCoordinatorTransactionalIT: removido um
thenCallRealMethod() estubado num método de repository Spring Data (proxy
sem corpo Java real, Mockito não consegue chamar); o @MockitoSpyBean já
delega pro objeto real automaticamente em qualquer chamada não estubada.

Corrige ChargeRepositoryIT: os dois casos que esperavam inserir uma charge
nova usavam ChargeTestData.aCharge().build(), que via Charge.restore()
monta uma charge com version=0 (representando uma linha já persistida).
Isso fazia isNew() reportar corretamente false e o save() tentar um merge()
numa linha inexistente. Trocado por Charge.create(...), a fábrica de
domínio real usada em produção para charges novas (version=null).